Look at current, then planned algorithms to check what values should be in variable type lists, etc. Current algorithms Interpreter TextToBr2 Cultural Translation Tool Character Breasoner Formula Finder Tree Node Deleter Music Composer Computational English Synonyms Program Finder No ideas/types (can base connections on names). Names will be propagated based on names, not types (note, interval). Names will also be, e.g. note, interval, as specified in predicate specifications. Should have [generic_predicate_name,3] and [$,generic_variable_name,2] (where generic_predicate_name requires specification to give predicate names) to replace names in reused code with those in specifications. Specification names are in the form [word1,word2,...] - Leave as $name1, and can take apart with atom concat The algorithm lists the options (e.g. philosophies for a back-translation of the original philosophy) for a level, [and x] [on closing the level, x] - skip philosophy, enter specs (manually convert philosophy into "back-translated"-like sentences which are spec basis) - To help with bottom-up (where both top-down and bottom-up may exist), a series of rcaw connections to predicates may exist, which the algorithm should try in increasing order of complexity to eliminate unnecessarily adding complexity to the algorithm. - Perhaps list arguments as lists of related groups, with lists of input and output and constants, i.e. "", to quickly find the sorted version of headers and constants *1 x use program finder style header-finding *2 x it is simpler it enter code x previous - Needs both *1 and *2, Needs a constant label so can insert the constant from data or a predefined list. *** Needs separate file - Need program finder header finder, but bug checker should find constants x do not find constants, which are in code, but substitute compound terms x dump, but may replace decomposition code with compound term decomposition code by first searching for the simplest form of header *** LATER x THIS TIME - If the method comes from the specification document, it might work, if it comes from re-entering specification data, it might not - The philosophy, or also, the algorithm may give the specification as input files, where if they provide no specification file, then past or new specification files are needed x only accepts previous, not new because this might fail and not save work * Also, the algorithm should convert philosophy with an algorithm - Perhaps it should try algorithms, then rename names afterwards (manually) - for each predicate - E.g. Leave (Music) Notes as inherited from the specification, and List2 instead of Interval (if top-down) so that can manually rename names - rules as data to check order, whether (and, or), whether asks to select - report towords - x convert them to strings at the start - Don't use types instead of names, because child predicates won't introduce new types that need types, and the specification should include all necessary names Make code generic if names in specification found from database don't match philosophy. - x Query new variable names using mind reading. - Add to database, can select main specification line (with predicate and variable names) names) in future - When has an algorithm, explain specification from algorithm base up (relation between variables) to find whether it is correct. Many not One Interpretation of a Specification Many not One Interpretation of a Specification - Group them (by storing the same data once x). - Preliminary specification-related requests for specifications that are near misses should list the near misses so that the user can develop new material. - A heuristic will calculate the specifications with the lowest near-miss score (from terms, data items and missing conditions for exception clauses, etc.?) - Near misses would be scored by data item (in term) instance gap distance (through other predicates, i.e. with clauses with stub pattern matching or mathematical stub conditions). It could do everything else but some pattern matching and mathematics by itself. - Near misses for pattern matching which didn't conform to a predicate format or for mathematical formulas, which weren't similar across a predicate, would be placed in a second tier. The select specification feature The select specification feature would be annoying to compare if it had groups (to cross-refer) and should be in one list to see how many changes each specification needed in one summary. An exact algorithm match would x fail because it is unoriginal (unless differently applied). It shouldn't stop with the single exact match because a slightly different version of the algorithm may be required. With a unique specification (based on a philosophy), algorithm writer will find a unique algorithm in terms of previous code. Without a specification, algorithm writer won't be able to calculate near misses or list recommendations. Near misses are calculated by comparing the difference between the status of a predicate on fail and its specification. The algorithm should keep and report a correctly functioning predicate and no more satisfying predicates reported for simplicity x they may be correct instead. The specification report should include the list number of working predicates (with a file of all x top 10 working predicates) and an overall score of each of the top 10 specifications. Specification Checker - The specification for a predicate would need to be complete (at least refer to previous data of each variable - at the minimum where the algorithm used each variable) to find suitable (at least child) predicates). A predicate constructor would decompose/process lists assuming biggest-smallest (list to check, list to compare it with) order, passing required variables (finding and testing the appropriate predicates' headers according to the specification as transformed by the interpreter), maximally x decomposing, string comparison performed by other predicates and assimilation of one-line predicates. The interpreter will interpret appropriate specification lines until the interpreter has finished, the algorithm writer should appropriately place decomposition/building function of a predicate, (there should be consideration of passing and handling of returned lists, such as whether they are necessary to return and if so, that a predicate will return them if they fit into a specification. The whole project including base cases will contain conditions that will need human correction), base cases may be empty sets, one-member sets and have data-dependent or human corrected conditions). It should store successfully constructed predicates. Plans may include markup for simulated intelligence handling of data, e.g. drawing the dot of the exclamation mark in the base case of character breasoner, writing lines of register machines, other conditions/parentheses in algorithms and member11 in character breasoner. Using common predicate formats, to correctly place list decomposition and building, could save time. Automating written specifications: philosophical words with similar specifications, or in fact may have an intermediate meaning file between the philosophy and specification that simplified finding specifications with a description of the specification (later automatically generated by, e.g. identifying formula finder, or another algorithmic method and editing out mentioning unimportant variables). Like a thesaurus, (with words in the philosophy linked to variable names through networks) the meaning file relates multiple words to a specification, for reuse of standard functions, such as file input and output. An algorithm would connect different specifications mentioned by the meaning together, using stock data to test, where data would be tested to be used, algorithms unique and each part needed (perhaps finding the usefulness in a philosophy by further frontiers of computational techniques, finding solutions to questions suggested by the philosophy/techniques corresponding to terms). Also, philosophy demands contrasting ideas, for example, connect notes and words, not rhythm and words (although this shows detail). Later, simulated intelligence would replace mind reading to fill knowledge gaps, such as user input, and create works from scratch. The meaning file would make the algorithm simple enough to have a mind-reading interface because it provides a single point that helps speed finding algorithms. - E.g. philosophy "I defined the word" - arrives at word (word), definition (sentence), considers whether to take the definition from user input or read it from a file and how to save it to a file (if it takes a word, this would not be worth inputting in a file). First, describe the relations between the names in the main specification x the names wouldn't need to be found from their relations because they would already be known - Would ask for names of names in subpredicates after selecting all required and requested predicates - Assign the specification to a group and save its predicate's names - Writing the predicates, keeping its names first solves the problem of writing the predicates or names then possibly changing its names for future uses.